超大模型工程化实践打磨，百度智能云发布云原生 AI 2.0 方案
人工智能开发领域的发展呈现出数据量和模型规模越来越大、模型训练速度要求越来越快的特点。然而训练和推理任务速度慢、资源利用率、应用成本高等工程化问题阻碍了人工智能应用的落地。
据 Gartner 预测，到 2023 年 70% 的 AI 应用会基于容器和 Serverless 技术开发。实际生产中，越来越多的 AI 业务比如自动驾驶、NLP 等也正在转向容器化部署。
近期 IDC 发布的《云原生 AI - 加速 AI 工程化落地》报告指出，云原生 AI 是连接 AI 应用和 IaaS 的桥梁，是加速 AI 工程化落地的关键。
云原生 AI 不是简单的“云原生+AI”，除了涵盖容器、K8s 等云原生的通用能力之外，面向 AI 工作负载，如何支持 GPU 等异构资源，如何提升资源效能，如何支持超大模型的预训练等，都需要对应的配套技术和长期工程实践，才能真正满足 AI 业务落地的场景。
基于国内顶级 AI 业务锤炼出的深厚经验以及丰富的技术积累，百度智能云正式发布云原生 AI 2.0 方案。
1. 融合大模型落地经验，云原生 AI 2.0 重磅发布
自从 2012 年深度学习在图像和语音方面产生重大突破后，人工智能便真正具备了走出实验室步入市场的能力。
千亿级甚至万亿级参数的超大规模模型的出现，如百度发布的“文心”等，向深度学习框架的算力调度、调优算法等提出了更高的要求。
百度智能云将超大模型训练（文心等）的经验，资源管理和资源利用率优化的经验，以及多场景工程实践的经验充分融合进云原生 AI 2.0 方案，用标准化的能力帮助企业应对缺乏大模型训练经验而导致的资源利用率低等问题，加速 AI 应用落地。
此次云原生 AI 2.0 版本在资源弹性、跨节点架构感知、训练推理效率等方面做了重点升级。
2. 剑指工程化问题，助力 AI 应用落地
那么，百度智能云的云原生 AI 2.0 方案解决了 AI 应用落地过程中的哪些工程化问题呢？
2.1 超大模型的预训练如何落地？
虽然大模型有诸多优势，但具体预训练过程却很难：比如有 3000亿条词语，需要 1750 亿的参数，这样的模型计算量大概是 314 ZFlops，其中 1 ZFlops 是 1024 EFlops，1 EFlops 又是 1024 PFlops，这是一个非常大的数量级。相关论文指出，如此的参数和样本量级，用 1024 张 A100 卡，也需要月级别才能完成训练，这对整个训练和技术架构的挑战都非常大。
模型预训练需要这么多的参数，也需要很多的计算资源，因此需要搭建一个集群来支撑整个预训练。搭建一个集群并非易事，这个过程会有很多不同的选择，比如单机如何选择，训练卡如何选择，训练卡内部的互联方式如何选择，多机之间又该如何架设网络保证它们之间能高效通信，网络规模又是怎样的。如何保证在有故障发生的情况下，模型能持续稳定的预训练，这些都是在集群建设中很关键的问题。
具体而言，大模型通常是指拥有复杂网络、稠密参数特点的模型，集合通信模式可以很好的支持这类模型的训练。为了更有针对性的建设支撑大模型预训练，云原生 AI 2.0 方案支持了支持了 PaddlePaddle 和 Pytorch+DeepSpeed 两种框架：
百度自研的 PaddlePaddle 框架，早在 2021 年 4 月份就推出业内首创的 4D 混合并行策略：数据并行、张量模型并行、分组参数切片并行、流水线并行。针对性能优化和显存优化，这几种策略相互组合，取长补短，能够在训练大模型时发挥各自的优势。
Pytorch 原生混合并行能力欠缺，针对大模型场景混合并行场景，微软推出的 DeepSpeed 开源库，做为 Pytorch 框架在大模型训练方向上的补充。
此外，业界还在 GPT-3 基础上进一步提出混合专家模型(Mixture Of Expert, MoE)，使得计算量不增加的情况下，参数量可以扩大到万亿，如Switch-Transformer。MoE 模式最大的特点是单个样本不再激活模型的所有参数，从而可以在控制计算量相对固定的情况下，极大程度的扩展模型参数容量。
在 MoE 模式下，可以将 Transformer 结构中的 FeedForward 部分看做一个专家，MoE 结构由多个专家共同组成，并通过路由（router）的方式将信息分发给不同的专家，最终对专家的输出结果在进行聚合，并最终产出模型推理的结果。深度学习框架会引入专家并行策略，来存放如此巨大的 Expert 参数。
我们将上述相关模式进行仔细分析后的结论如下表（以 1000 亿参数模型为例）：
很多企业因为缺乏上文提及的大规模集群实践经验而无法顺利完成超大模型的预训练，百度拥有8 年多的万卡规模 EFlops 算力最佳实践的能力和积累，等效算力高达50%以上，数千卡并发训练线性加速比 90%，整体大模型预训练的集群利用率高达95%。
在 2022 年 6 月 30 日最新发布的 MLPerf Training v2.0 榜单里，百度使用飞桨（ PaddlePaddle ）框架和百舸异构计算平台提交了 BERT Large 模型的 GPU 性能结果，在同等机器条件下性能排名世界第一，向全世界展现了百度智能云的性能领先性。借助这些经验积累，百度智能云的云原生 AI2.0 方案针对超大模型的预训练提供了以下特色能力：
网络：全 IB 网络，盒式组网最大规模，单机转发延迟 200ns，千卡通信近线性扩展。
通信库：自研的异构集合通信库 ECCL。由于业务会面临很多不同代的 GPU，不同的异构芯片，如何把所有的芯片都高效使能起来，是要解决的一个关键问题。同时，在大规模上还需要解决一些拓扑探测、拓扑感知的问题，也会放在通信库中解决。结合上面的分析，我们知道混合并行模式下，不同并行模式对网络通信的需求是不同的。而集群中的硬件在机内和机间的不同层次，提供的通信能力也是不同的，通常情况下机内通信带宽最高，而机间同号卡通信效率最高（在 8 导轨优化网络拓扑下）。为了更好地使二者结合，就需要在调度及框架侧做好任务分配。而任务分配的前提是让训练任务知道集群硬件连接方式，也就是拓扑感知能力（如下图所示）。硬件拓扑感知需要同时感知单机硬件连接方式与集群网络连接方式，其中涉及 PCIe、网络探测等诸多细节，我们将硬件拓扑感知的能力封装到 ECCL 通信库中，并作为集群标准的基础接口提供给上层的调度器和训练框架，从而联动配合地使能最高训练效率。
调度：跨节点架构感知高性能调度，支持通过慢节点感知发现分布式训练节点的性能瓶颈。在千卡规模的弹性训练的场景下，调度结合框架，能够提供容错功能，保证大规模训练的稳定性。
可观测：自研面向模型并行的多机调优 profile 工具，能够发现任务/数据分配不均等问题，经过优化的最终端到端吞吐可提升 1 倍以上。
实际上，不仅仅是超大模型预训练实际场景沉淀出的特色能力，云原生 AI 2.0 还对资源弹性、训练推理效率、易用性等通用能力做了全面升级。
2.2 如何保证资源的弹性？
GPU、NPU 作为主要的 AI 算力资源，品牌型号多种多样且价格昂贵，如何有效的让这些算力资源充分发挥作用、提高资源利用效率，是资源管理层面需要解决的问题。
借助以容器为代表的云原生技术能够对 CPU 进行有效的虚拟化进而提升资源的利用率，但是容器技术不能直接被应用到 GPU 等算力上，需要做一定的技术升级和改造。
改造之后就可以将 GPU 等 AI 算力作资源虚拟化以及资源池化，能够将 AI 应用和 GPU 服务器硬件解耦，实现虚拟 GPU 资源的动态伸缩和灵活调度。百度智能云针对以上关键技术也实现了如下能力：
GPU 容器虚拟化：2.0 版本提供了用户态和内核态两种实现，用户态能够实现进程融合、显存交换、编解码实例等，性能更好；内核态隔离性强，可以实现算力隔离以及显存隔离，用户可以根据自己的需求灵活选择。
用户态方案：通过拦截 Driver API 进行资源隔离或限制操作，实现显存隔、算力隔离基础隔离功能及显存超发、高优抢占等高级功能。
内核态方案：内核态方案主要由拦截接口跟拦截驱动两部分组成。
下图中分别使用了单内核态 GPU 容器与单 GPU 容器直通跑任务测试（ 测试环境与模型：resnet50，batchsize=32，在v100-32GB ），可以看出内核态 GPU 容器几乎没有性能损失。
分别使用用户态 GPU 容器与内核态 GPU 容器跑任务测试（ 测试环境与模型：resnet50，batchsize=32，在 v100-32GB ），从下图中的数据结果（单位：平均吞吐(Img/sec)）可以看到用户态方案性能比内核性能高 8%-10%；而内核方案隔离性更强，几乎没有性能损失。
调度策略：支持共享混部，拓扑感知以及亲和调度。
资源管理：池化架构，资源被统一动态管理，避免资源浪费，实时调度减少资源碎片。
国产化适配：支持昆仑芯等国产芯的虚拟化和调度。
实践中，上述能力给业务带来了真金白银的实际收益。
比如，百度商业广告模型迭代经过多年的发展，广泛使用 GPU 等异构硬件进行预估和训练加速，以支持更加复杂的点击率、转化率、相关性等模型的创新和发展，直接驱动大商业的收入增长和用户体验改善，收益显著。
这带来了 GPU 需求的不断增长。但是存量 GPU 资源使用率低是一直存在的问题，导致了资源的浪费。当时采用粗暴单实例独占 GPU 卡的使用方式，加上流量呈高低峰态、模型复杂度不一、业务模块使用异构计算资源的限制等问题，导致了整体 GPU 资源利益率也仅 13%。
面对这种情况我们上线了基于 GPU 容器虚拟化的在离线业务混部方案来提升 GPU 的整体资源利用率，优化后的商业在线业务 GPU 共享部署的占比 90%+，整体 GPU 利用率高达 50% 左右，在线业务 Latency P97 性能保持不变 。
2.3 如何提升训练、推理任务的效率？
为了更好地加速训练和推理任务，在训练场景下如何实现分布式训练的加速以及数据的加速？AI 镜像会有复杂的 CUDA 依赖，甚至会有一些驱动和镜像本身比较大，严重影响启动的速度，如何针对性进行优化？
云原生 AI 2.0 推出了 AI 加速套件 AI Accelerate Kit（简称 AIAK），该套件基于百度智能云 IaaS 资源推出的 AI 加速能力，用来加速 Pytorch、TensorFlow 等深度学习框架的 AI 应用，能极大提升分布式训练和推理的性能。
分布式训练加速：AIAK-Training 是基于 Horovod 深度定制优化的分布式训练框架（Horovod 是 TensorFlow、Pytorch 等的分布式深度学习训练框架），在保留 Horovod 已有功能特性的基础上，增加了新的通信优化特性，完全兼容 Horovod 原有 API，经典模型的训练效率提升 50% 以上。
推理加速：AIAK-Inference 通过图优化、算子融合和自研高性能算子库来提升推理效率，ResNet、Bert 等经典模型时延降低 40%~63%。
I/O 加速：通过并行文件系统和分布式缓存技术，与对象存储数据双向流动，实现数据集的管理和读写加速。并行文件存储 PFS 提供完全托管、简单可扩展的并行文件存储服务，针对高性能计算场景提供亚毫秒级的访问能力、高 IOPS 及高吞吐的数据读写请求能力；分布式缓存加速 RapidFS 是由百度智能云推出的高可靠、高可用、弹性的数据加速服务，以对象存储作为数据湖存储底座，为计算应用提供统一的数据入口、命名空间及访问协议，加速海量数据分析、机器学习、AI 训练等业务访问存储的性能，方便用户在不同的存储系统管理和流转数据。
在 4v100-32g 机型 ImageNet 1K 训练中，PFS + BOS 和 RapidFS + BOS 效果和本地 SSD 持平，比直接基于对象存储 BOS 训练提升 5 倍以上。
镜像加速：通过容器镜像按需加载技术，缩短镜像下载时间，实现容器冷启动加速。百度智能云容器镜像服务 CCR 提供的镜像加速功能，可在用户推送镜像时自动生成符合 OCI 镜像规范的加速格式的镜像。加速版本的镜像为镜像层中的每个文件和数据块建立索引，配合镜像仓库的 HTTP Range Request 的特性，使单机侧支持按需下载部分镜像层的文件。CCE 提供的镜像加速组件可一键为 K8s 集群开启/关闭镜像加速能力，并在容器调度前自动为容器”换装“加速镜像。
在基于内容生成视频的业务场景中，镜像按需加载将容器冷启动速度提升 6-20 倍。
2.4 如何加速 AI 作业开发，降低人力成本？
强大的 AI 编排能力，让实验更轻松
支持通过 YAML 静态定义以及 Python DSL 动态定义以及界面定义，用户接口简单，易于上手。
抽象节点的输入 Parameters 和输出 Artifacts 以及运行环境 Env，并以文件的方式做快照，方便追踪训练过程，为实验过程可复现和 AI 编排可视化打下基础。
内置丰富的 PaddlePaddle 的套件，如 PaddleDetection、PaddleNLP、PaddleOCR 等，可以满足许多产业实践的 AI 训练需求。
DAG 调度功能丰富，满足 AI 训练的调度需求
支持复杂的定义，如循环、递归、条件分支、节点屏蔽、定时和周期调度等，以满足大部分 AI 场景的调度需求。
通用的架构设计，PaddleFlow 工作流亦可支持运行在云原生 DAG 调度 Argo、Airflow 等其他主流 DAG 调度上，满足更多企业内部定制化需求。
针对 DAG 运行全方面优化，提升 DAG 执行效率
通过节点产出数据统一管理，自动跳过未发生变化的节点，缩短 DAG 运行时间。
通过感知节点产出临时数据位置，减少中间数据读写的频率和远程访问频率。
通过 AI 资源调度的异构能力，检测节点的运行环境（CPU、GPU 等）按需调度不同节点，降低算力占用成本。
3. 总结
作为国内人工智能的「头雁」，百度正通过自身的经验和技术输出来不断降低 AI 技术开发和应用的门槛。
目前，云原生 AI 2.0 已经融合进百度百舸·AI异构计算平台，大家可以在百度智能云官网搜索“百度百舸”，加速 AI 应用，激发业务想象力。
- - - - - - - - - - END - - - - - - - - - -
点击阅读原文，了解百度云原生 AI 2.0 更多内容
传送门